fix(rpc): prevent memory exhaustion attack in eth_getStorageAt by limit#9
fix(rpc): prevent memory exhaustion attack in eth_getStorageAt by limit#90xbigapple wants to merge 1 commit intodevelopfrom
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 2 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="framework/src/main/java/org/tron/core/services/jsonrpc/TronJsonRpcImpl.java">
<violation number="1" location="framework/src/main/java/org/tron/core/services/jsonrpc/TronJsonRpcImpl.java:538">
P2: The new storage index validation still accepts `"0x"` (empty hex), which is then interpreted as storage slot zero instead of being rejected as invalid input.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
framework/src/main/java/org/tron/core/services/jsonrpc/TronJsonRpcImpl.java
Show resolved
Hide resolved
…iting storageIdx length
0xbigapple
force-pushed
the
fix/storageIdx-dos-vulnerability
branch
from
8159da1 to
1be7ee5
Compare
1 participant
What does this PR do?
This PR adds a defensive length check for the
storageIdxparameter in theeth_getStorageAtJSON-RPC method before it is hex-decoded. It enforces a strict maximum length (66 characters with the0xprefix, 64 without) and correctly rejects empty strings, throwing a standard-32602Invalid Params exception.Why are these changes required?
To prevent a resource exhaustion (DoS) vulnerability. Without this length check, an attacker could supply an exceptionally large, multi-megabyte hex string as the
storageIdx. The underlyingByteArray.fromHexStringmethod would attempt to allocate a massive byte array in the JVM heap during decoding, potentially leading to immediate memory exhaustion (OOM) and node crashes. This aligns our RPC security with execution layer standards (similar to Ethereum's recent fix in go-ethereum PR #32750).This PR has been tested by:
JsonrpcServiceTest.testGetStorageAt)Follow up
None.
Extra details
Summary by cubic
Adds input validation to
eth_getStorageAtto prevent memory exhaustion by rejecting blank,0x-only, or oversizestorageIdxwith-32602Invalid Params. This blocks DoS attempts while keeping valid 32-byte keys working.storageIdxrules: max 64 hex chars (66 with0x), not blank, and not just0x.0x/oversize indexes and keep tag validation using a minimal valid index.Written for commit 1be7ee5. Summary will update on new commits.